home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19941221-19950208
/
000011_news@columbia.edu_Fri Dec 23 15:59:54 1994.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
5KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14446
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 23 Dec 1994 11:00:01 -0500
Received: by apakabar.cc.columbia.edu id AA17092
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 23 Dec 1994 10:59:57 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: HANGUP problem on FreeBSD
Date: 23 Dec 1994 15:59:54 GMT
Organization: Columbia University
Lines: 72
Message-Id: <3des5q$gm2@apakabar.cc.columbia.edu>
References: <3ddrrl$hc@cruella.ee.pdx.edu>
Nntp-Posting-Host: watsun.cc.columbia.edu
Keywords: HANGUP timing FreeBSD DTR
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3ddrrl$hc@cruella.ee.pdx.edu>,
Roland Kwee <rkwee@ee.pdx.edu> wrote:
>Issuing the HANGUP command on my FreeBSD system drops the
>DTR line forever, instead of just 0.5 second, as explained
>in the C-Kermit book (page 45). I use the modem setting 'direct'.
>
>On my Linux system, the command works according to the book.
>It is a problem for me, because I try to connect both systems
>with a direct line and SLIP, and the HANGUP command should
>cause the other machine to logout. However, I found no way
>to get the DTR on the FreeBSD box back to ON! (except SET LINE).
>
>Can anyone tell me if this is supposed to depend on the OS?
>If it may be a bug? How to turn DTR to ON?
>
It is supposed to work as described in the book.
During (and after) the development of C-Kermit 5A(190), FreeBSD kept
changing out from under me. I received numerous "patches" from all over
the world, most of them mutually contradictory.
As you have probably seen by inspecting the tthang() routine in ckutio.c,
the simple act of dropping DTR for half a second is one of the hardest
things to do in non-vendor-specific UNIX communications software, since
there are so many different ways to do it -- each system has its own way.
tthang() presently takes up 405 lines of code, and still fails to work in
some cases, like yours.
The POSIX method is used In the FreeBSD case -- relatively straightforward
(get current speed, save it, set speed to 0, sleep half a second(*),
restore speed), so if it doesn't work, there is probably something wrong
underneath -- i.e. in FreeBSD or your serial port driver.
All I can say is, you are free to make changes to tthang() and send them
to me, but don't have any confidence that your changes will work for any
length of time, given FreeBSD's track record on stability so far (speaking
as an outsider, no offense intended). I don't have access to any FreeBSD
systems to do this work myself. Also, in my correspondence with other
FreeBSD users, nobody has reported a problem like this, so it's very
likely peculiar to a specific configuration (kernel edit, driver edit,
whatever).
>In general, is there a way with Kermit to set ANY of the handshake lines
>to arbitrary values? Would be neat for testing all kinds of things.
>
This would be a great feature, but no, there is no standard or portable
way (not even several standard ways) to set arbitrary modem signals.
C-Kermit does have a "show modem" command, which works on the (few) UNIX
variations that allow modem signals to be tested. HP-UX probably has the
best serial i/o interface I've seen; very few others even approach it.
UNIX "standards bodies" have vigorously avoided the area of serial
communications, which, even in this age of low-cost, high-speed modems and
the worldwide public stampede to the "on-ramp" of the "information
superhighway" -- a time when serial communications is becoming more
important than ever before.
POSIX made some progress, but it's only one of many APIs, and even the
POSIX.1 API is inadequate. It does not address questions of exclusive
access (which leaves us, still, with the "UUCP lockfile" -- one of the
most atrocious ideas in software engineering ever to gain "de facto
standard" status, ranking right up there with cooperative multitasking,
with which it has more than a little in common), hardware flow control,
modem signals, nondestructive input-buffer peeking, or fine-grained (under
one second) sleeps, all of which are essential for serial communications.
(*) But since there is no way to sleep for half a second in POSIX,
we have to use some kind of non-POSIX-compliant method, i.e.
an "extension", and this might be a good place to start
looking for the problem. See the msleep() routine in ckutio.c.
- Frank